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Abstract 

Decision taking can be performed as a service to other parties and it is 
amenable to outtasking rather than to outsourcing. Outtasking decision 
taking is compatible with selfsourcing of decision making activities carried 
out in preparation of decision taking. Decision taking as a service (DTaaS) 
is viewed as an instance of so-called decision casting. Preconditions for 
service casting are examined, and compliance of decision taking with these 
preconditions is confirmed. Potential advantages and disadvantages of 
using decision taking as a service are considered. 



1 Introduction 

This paper has been written with the objective to state and answer the question 
to what extent it is possible and meaningful to use and to offer decision taking 
(DT) as a service, hereafter abbreviated as DTaaS. 

For the definition of decision taking that I will use, I refer to |Bj. That 
definition is unusual in the sense that a decision is an action rather than a 
result of an action. 

1.1 Service casting and service casting preconditions 

DTaaS will be understood as a substitution instance of the context [-]aaS where 
DT is placed in the "hole". Thus DTaaS abbreviates [DT]aaS. For an activity 
or entity or process X, XaaS = [X]aaS is the service casting of X. In particular 
DTaaS represents the service casting of DT, provided that DT satisfies the 
constraints that any X must comply with for [X]aaS to make sense, that is to 
be well-defined. These constraints are called service casting preconditions. The 
task of this paper is twofold: (i) to determine a reasonable account of the service 
casting preconditions in general, and (ii) to argue why DT, and to what extent, 
complies with these service casting preconditions. 
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1.2 Parametrized roles 

S abbreviates service and [-]aaS stands for the service casting operator X — > 
[X]aaS. S can be considered a role and the service casting operator can be 
understood as an instance of the so-called generic role casting operator which 
takes role Y to the role casting operator [-]aa[Y]Q 

Below I will make use of the role casting operator [-]aa[F] where F stands for 
feature. XaaF views X (or instances of X) as a feature of entities or processes 
that realize some form of X. Speaking of XaaF indicates that an entity realizing 
X may keep its identity even if X is stripped from it. 

Role casting preconditions indicate for which roles Y, [-]aa[Y] is a valid 
role casting operator. I will avoid this level of generality and I will assume 
that "service" satisfies suitable role casting preconditions without making an 
attempt yo analyze these in detail. 

1.3 Decisions and units 

In [3T] the observation is made that decision making research mainly stands 
on two feet: description and prescription; a similar dichotomy underlies the 
survey |32j . The same may hold for work on decision taking. I will avoid both 
description and prescription, and instead focus on the structure of organizational 
processes. I will understand decision making and decision taking as structural 
mechanisms independent of existing practice. Decision taking constitutes an 
organizational control mechanism. 

Following [TQl [TT| I will speak of units to indicate all forms of organizational 
entities. Units may be equipped with a hierarchical structure with subunits 
at various levels. Sourcements (see [9]) are descriptions of sourcing relations 
between units. Outsourcing and outtasking are examples of sourcement trans- 
formations. 

Decision making (DM) can be split in two parts: decision preparation (DP) 
and decision taking. In symbols: "DM = DP + DT". Because DT is usually 
connected with leading roles and a unit will not function without leaders, it is 
implausible that DT is outsourced together with the sources (leaders) responsi- 
ble for it. 

Some authors (e.g. see [H]) read decision taking as the reception of a decision 
outcome in the role of staff responsible for realizing the goals of the decision 
taker. Although this is an acceptable interpretation of decision taking I will 
deviate from it. I will not have a special term for the action or process of taking 
notice and subsequent comprehension of a decision outcome. Other authors, 
e.g. in |37] use decision taking as an equivalent of decision making, a use of the 
terminology that I am not following either. 

In [3] decision making and decision taking are distinguished in a way that 
comes close to the interpretation of [6] by accepting the real time character and 
the situational dependency of decision taking, in contrast with decision making, 
but without assuming the convention that a decision is an action. Below I 

1 [-]aa.S = (let Y = S in)[-]aa[Y]. 
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will make use of so-called outtasking of decision taking. Admittedly this is an 
uncommon phrase; it is related to delegation of decisions as found in [36] and 
in 

In [5T] the outsourcing of self-governent is analyzed as a philosophical theme. 
The analysis leads the author to formulating doubts concerning the mentioned 
notion. These doubts are grounded in both the human nature of the outsourc- 
ing agent and in the comprehensiveness of the range of decisions supposed to be 
outtasked. In the terminology that I prefer to use, outtasking would be prefer- 
able to outsourcing for the use made of in in [IT], because the human agent, 
viewed as a unit, cannot possibly export any of its internal sources (given today's 
biotechnology at least) to an external unit. 

1.4 Organization of the paper 

DT is contrasted with voting and promise issuing in Section [2] then in Section 
[3] DT is viewed as a feature of organizational behavior. A comparison with 
computer program structuring is made, and it is described how an organization 
may proceed if it makes no use, or limited use, of the DT feature. In Section [4] 
the concept of service casting, that is casting an entity class or an activity class 
(concept) as a service, is examined in rigorous detail. Several examples of ser- 
vice casting are considered and service casting preconditions as well as service 
casting obstacles are collected. In Section [5] the particular case of service cast- 
ing DT is approached by indicating how DT complies with the service casting 
preconditions and avoids a match with the service casting obstacles. In Section 
15.31 possible rationales for making use of DTaaS are surveyed and a preliminary 
risk analysis for DTaaS are provided. In Section [6] the intended audience for a 
theory of DTaaS is specified and the intended yield for those in the intended au- 
dience of acquiring familiarity with our theory of DTaaS is formulated. Finally 
in Section [6] some conclusions and directions for further work are mentioned. 

2 Voting and promise issuing 

With X C Y (X is a subclass of Y) it will be formalized that every instance 
of X is an instance of Y. X-Y denotes the class of instances of X that are not 
instances of Y. With ACT denoting the class of actions and with CH denoting 
the class of choices (acts of choosing from a menu of alternatives) it follows that 
DT C ACT, CH C ACT, while DT and CH arc not disjoint and neither one is 
a subclass of the other. If by default (but not necessarily always) instances of 
X are also instances of Y that relation between X and Y is denoted as X C d Y. 
It follows that X C Y implies X C d Y. Individual voting (IV) is a subclass of 
choice: IV C CH. Social choice (SC) is an aggregate of which IV's are a part 
(component) rather than an instance. Concurrent IV's are collected in a group 
vote (GV) which itself is embedded (used as a phase in) social choice. Now, CH 
C d ACT-DT, GV C d ACT-DT, and SC C d ACT-DT. 

Promise issuing (PI) is a class related to DT. Below c(X) will denote the 
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complement of X. PI C d c(IV U GV U SC). Further PI C d ACT-CH, that 
is, most most acts of issuing a promise are not choices. Obligation creating 
promise issuings (OCPI) arc a proper subclass of PI, so OCPI C PI. Instances 
of OCPI arc not decisions however: OCPI C ACT-DT. It then follows that DT 
C PI-OCPI. 

For a class of actions will consider XaaS plausible (abbreviated: pl(XaaS)) 
if there for most instance of X it is conceivable in technical terms that these are 
provided as a service. I will consider XaaS implausible if it is not the case that 
XaaS is plausible. Now I will use the (defeasible) rule that if X C d Y & pl(YaaS) 
=> pl(XaaS). This rule can be applied with X=PI-OCPI and Y=DT, leading 
to the somewhat unexpected conclusion that pl( [PI-OCPI] aaS), for which an 
opportunistic style of marketing may serve as an example. 

These matters are far from obvious (and may well be disputed), and for 
that reason I will now expand on the underlying arguments which led to these 
assertions in some detail. 

2.1 Voting, social choice, and decision 

For the purpose of this paper the boundaries of decision must be laid down 
with more precision than has been done in [BJ. In [BJ the distinction between 
decision and choice has been discussed extensively, with the effect that (i) an 
act of choice need not be a decision and, (ii) that a decision need not involve 
choice. 

However, between choice and decision there is voting, as well as social choice. 
Related to decision is promising (promise issuing). I hold that voting, social 
choice, and promising by default (that is in most cases) do not constitute de- 
cisions. Clearly understanding the difference between promising, voting, social 
choice, and decision is necessary because neither voting, or social choice, nor 
promising can be cast as a service. 

2.2 Voting and social choice 

In order to distinguish voting from decision taking I will make the following 
assumptions about voting: 

1. Casting a vote (by an individual voter) is an act of voting. 

2. Each act of voting is an instance of choice. 

3. The result of casting a vote (by an individual voter) is an individual voting 
outcome (IVO)i 

2 An IVO is often referred to as a vote but that terminology is confusing as a vote may also 
refer to an act of voting, which I prefer as its meaning. It may even refer to the fact that an 
agent has the right to vote. The common use of the term vote seems to variy between static 
and dynamic interpretations just as the term test in software engineering does (see I29I V 
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4. Individual voters act concurre ntlyH while together performing a group 
voting process. 

5. A group voting process terminates and subsequently the plurality of col- 
lected IVO's can be aggregated to a single AVO (aggregate voting out- 
come) by means of some aggregation methodQ 

The design, analysis, and selection of aggregation methods for votings 
belongs to the area of social choice theory. There exists a large volume of 
theory on voting and social choice for instance [34j [43] , most of it not in 
need of notions like IVO and AVO. An AVO is frequently referred to as a 
decision, thus reflecting a point of view that I do not share. 

6. The AVO is merely the outcome of the overall voting process, and it must 
be distinguished from the consequences of putting it into effect. 

7. Depending on the particular organization of the group of potential voters 
as well as depending on its objectives, casting a vote may range from being 
an instance of making a choice to being an instance of taking a decision, 
with in between acts of voting that constitute a class of their own. Here 
are two extremes: 

• If the voting outcomes cannot be traced back to individual voters 
(anonymity), and if the voter cannot predict the impact of his/her 
particular choice made when voting, the IVO will not have the form 
of impact the voter expects from a decision outcome, and for that 
reason its coming about will not count as a decision. 

• If the vote is open and if the voter can reasonably predict the impact 
of its own contribution to the aggregate outcome, the individual vot- 
ing outcome may be considered a decision outcome and the preceding 
act of voting may be considered a decision. 

8. In some cases a decision outcome needs to be confirmed (ratified) after- 
wards by some body with higher authority. Then the action producing 
that "decision outcome" still counts as a decision if it was taken with 
the expectation that ratification will succeed. This leads to the following 
pipeline: 

• A process involving different levels and stages of decision taking and 
social choice leads to the listing of persons that may be elected in 
office. 

3 This form of concurrency can be adequately formalized with arbitrary interleaving based 
parallelism, for instance using the process algebras specified in |4j. 

4 Making an aggregate social choice (and thus producing an AVO) as implemented by means 
of voting is in most cases not an instance of decision taking as understood in [6] because the 
aggregate agent has no intentions which it is aiming for and because it makes no predictions 
about the consequences of putting the AVO into effect. Social choice, is not an instance of 
choice and social choice is not necessarily an instance of decision cither. By default it is not. 
In fact, In many political systems social choice is a more powerful mechanism than decision 
taking. 
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• Social choice mechanisms, often based on voting, are used to select 
who will be in office for some period. 

• Persons in office enact decision taking, for that task they may be 
supported by non-elected staff for decision making (decision prepa- 
ration) . 

• Decisions must be ratified afterwards by means of small scale so- 
cial choice (normally involving non- anonymous voting), performed 
by bodies of agents who have been put in place for limited periods of 
time by social choice mechanisms implemented by way of anonymous 
voting. 

• The primary responsibility for the (consequences of effectuating the 
outcome of the) decision remain with the agent who took the decision, 
who is by default assumed to expect ratification. 

9. Confidential boardroom voting with individual voting outcomes open to 
all participants may be in some cases be considered an instance of decision 
taking, whereas the voting that takes place with national elections in so- 
called democracies does not. Indeed I will assume that a small group 
of persons constituting a board, which is engaged in open and personal 
discussions, can have intentions in spite of possible differences of opinion, 
whereas a large group of individuals cannot be attributed an intention on 
the basis of the interpretation of an AVO that came out of a group voting 
process in which these individuals had been invited to participate 

One may contemplate voting as a service (VaaS). In some cases it is ad- 
missible that an individual outtasks a voting assignment to another agent. It 
is implausible, however, that an agent specializes in voting on behalf of other 
agents on a systematic scale. For this reason I consider VaaS to be an implausi- 
ble notion. Precisely this observation necessitates making a distinction between 
voting and deciding in preparation of contemplating DTaaS. 

2.3 Promise issuing 

Promising, that is, issuing a promise, is an action comparable to but yet different 
from taking a decision. This matter needs to be analyzed at this point because 
it impacts on the plausibility of DTaaS. For the notion of a promise I refer 
to [17l [18j [7] . As discussed in [6] there is a connection between promise and 
decision. This connection would be simpler and more symmetric if a promise 
were understood as an act of promising. Because that convention would deviate 
too much from common usage I will not primarily understand a promise as an act 
of promising but rather as its outcome. A promise is the tangible or intangible 
outcome of an act of promising and promise issuing (PI) is performing the act 
of promising. 

5 The social choice processes supposed to be supported by the forms of reasoning as sug- 
gested in [5] may also count as decision taking in my opinion. 
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There is remarkable complementarity between promise issuing and voting. 
Both voting and promise issuing produce an outcome from which further con- 
sequences may result. Voting involves choice, but it need not be the expression 
of an intention or of an expectation. Promise issuing involves intentions and 
expectations but it need not involve choice. 

I will distinguish promise issuing from promise making, with promise issuing 
referring to the action, and promise making referring to a more comprehensive 
process of which promise issuing constitutes the concluding phase. Promise 
making may include preparatory steps, mainly for designing the form and the 
content of the promise (also called promise body in [7]). 

Promise issuing is close to decision taking but it differs in important ways. I 
suggest the following relation: every decision outcome is a promise but not the 
other way around^ Promise is more general than decision outcome because: (i) 
the promiser (comparable to the decision taker) need not have any expectations 
concerning the consequences of effectuation of the promise, (ii) the promise may 
be intangible (like a mathematical entity, which stands for a shared cognition) 
while a decision outcome must be tangible, (iii) the role of a promisor is imma- 
terial, (iv) if a promise has an intangible form, for instance two or more agents 
remembering that something was said, then the consequences of the promise 
are mediated via the different components of the promise (that is the cognitive 
residues of the act of promising as they exist in different agents that were in 
scope of the promise, including the promiser) and not via the single "promise" 
(viewed as an outcome of promise taking), (v) the scope of a decision outcome 
is merely its readership as prescribed by the decision taking protocol at hand, 
whereas the scope of a promise (see [7]) is more immediately determined by the 
act of promising involved. 

The reason to consider promise issuing in some detail arises from the follow- 
ing observation: "promise issuing as a service (PlaaS)" is a problematic (that 
is, not necessarily plausible) concept because (i) it is unclear how promise is- 
suing can be delegated to another agent, (ii) it is unclear what it might mean 
to be more capable of promising on behalf of a promiser than the promiser is 
him/herself Q I conclude that although DT is a subcategory of PI, for PI in 
general PlaaS is a problematic notion. At the same I intend to maintain that 
DTaaS is a coherent (potentially plausible) concept. 

So it must be the case that especially for cases of PI that do not qualify as 
DT provision as a service is implausible. A criterion that separates promises 
for which PlaaS is implausible from decisions is the concurrent creation of obli- 
gations for the promiser. Some promises create obligations for the promisor^ 

6 The viewpoint that each decision is an instance of promise issuing derives from the formal 
definition of a promise in [jj. For different definitions of promise issuing the relation with 
decision may work out differently. 

7 "Marketing as a service (MaaS)" is a plausible notion, and some forms of MaaS might 
be viewed as an instance of PlaaS. The difficulty with understanding PlaaS is immediately 
connected to the difficulty of explaining the precise role of promises. The abundance of 
promises "in the real world" seems not to be based on the existence of a definite semantics of 
the term promise but rather on its absence. 

8 According to 1171 1181 [7J promise issuing need not involve the creation of an obligation 
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Obligation creating promise issuing is not an instance of decision taking. It 
appears that "obligation creating promise issuing as a service (OCPIaaS)" is 
an implausible notion. That implausibility renders PlaaS problematic, but not 
DTaaS. 

3 DT as an (organizational) feature (DTaaF) 

Besides interpreting decision as an act rather than as an outcome I will consider 
it to be a feature of organizational structure, amenable for analysis in terms 
organizational design and architecture, rather than as an aspect of human be- 
havior primarily amenable to empirical investigation. DTaaF is a perspective on 
DT which allows to assess from an external perspective which activities count 
as DT and which do not. DTaaF also allows the view that an organization may 
be transformed as to feature more (or less) DT, that is to have more (or less) 
frequent occurrences of activity classified as DT. 

Decision taking is a concept that emerges from attempts to modularize the 
behavior of existing or imagined organizations, rather than a concept which 
emerges when considering the behavior of single individuals or the collective be- 
havior of groups of individuals^ I will follow [6] with the following assumptions: 

1. A decision is an act of decision taking with actor (agent), time and place 
as required coordinates. 

2. A decision must produce a decision outcome which is a tangible item for 
instance a text. 

3. The effectuation of a decision outcome leads to the consequences of that 
decision outcome (sometimes abbreviated to "consequences of the deci- 
sion"). 

4. Every decision is taken by an agent with the intention that effectuation of 
the resulting decision outcome has the expected consequences; it depends 
on the role of the decision taker who needs to take care of effectuating the 
decision outcome. 

5. If agent a takes a decision that is action is performed in the context of a 
playing some specific role, without that role being known or specified a's 

for the promiser. In particular promise issuing by automated agents must be viewed as 
autonomous action. 

9 In psychological research it seems to be taken for granted that many forms of behavior, 
including most forms of human choice, may be considered instances of decision making, which 
is usually not distinguished from decision taking. I disagree with that usage of the language to 
the extent that in my view when making a choice is observed no decision taking is necessarily 
implied. Choice takes place whenever an agent acts in a setting where the agent was aware of 
alternative actions that it might have performed instead in full compliance with operational 
constraints of the setting. An animal may also perform choices even if it is harder to determine 
the meaning of awareness in that case. That an animal is able to take decisions is implausible 
according to [6]. 
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production of a decision outcome amounts to no more than a mere speech 
act, 

6. Rather than the choice between different options, the production of an 
intermediate product (the decision outcome) is the primary feature of a 
decisionF°l 

7. In the absence of a decision outcome, the effectuation of which brings 
about the intended consequences (as expected by the decision taker), mak- 
ing a choice between different behavioral options amounts to a choice and 
a choice may be made in the absence of a decision. 

8. The only obvious alternative to a decision is not to take that decision 
(with the same coordinates and producing the same outcome), (ix) deci- 
sion taking is a concluding subprocess of decision making, decision making 
primarily involves for instance the preparation of decision outcomes; de- 
cision making is embedded in a larger decision making process which also 
involves protocol actions that do not influence decision outcomes. 

9. A decision terminates an episode of indecision. 

10. A decision is an action but it need not be a decisive action, while a decisive 
action need not be or involve a decision. A decision is a decisive action 
only if in hindsight it appears that effectuation of the decision outcome 
had decisive consequences. 

11. Making up one's mind in preparation of an action is not an instance of 
decision taking. 

12. A command is the outcome of an act of commanding (command issuing) 
and it is like a decision but it indicates in addition who who has to act. 
If the command is tangible it comprises a decision, but if it is intangible 
the command is a speech act which fails to count as a decision. Thus: 
command issuing that leads to a tangible command (outcome oriented 
command issuing) produces a decision at the same time, whereas on the 
fly command issuing produces an intangible command only which does 
not count as a decision. 

In addition to what was stated in [6] it is required that a decision outcome is 
largely self-explanatory. A mere bit (0 or 1, usually termed "yes" or "no") is 
insufficient in the absence of an unambiguous reference to a rendering of the 
question to which that bit is supposed to constitute an answer F*l 

10 Typically a car driver makes choices which do not qualify as decisions when handling the 
controls of the car while in motion. However, the step to install a car kit for a mobile phone, or 
the step to buy a new map or a (new) navigation device, may or may not be the consequence 
of a decision. For instance if a form is created and signed to instruct a car dealer to install a 
new car kit, that form may be understood as a decision outcome of the car owner's decision 
to acquire a new car device. But if besides buying food, fuel, and newspaper, a map is bought 
because of its fresh look and feel, the latter action may not count as having been done as an 
effectuation of a decision outcome. 

11 When voting an agent may choose "yes" (or "no") unaware of its implications or meaning. 
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3.1 Remote method invocation as an analogue 



My perspective on decision taking is derived from a perspective on activity found 
in the area of computer programming. When observing a machine effectuating 
an instruction sequence one sees no more than a sequence of steps. That the 
instruction sequence has been written in a so-called structured notation is a 
matter of conceptual organization at a higher level of abstraction. 

For instance it might be stated that a certain sequence of steps is best gener- 
ated by effectuating a method call from an appropriate class thus providing the 
additional judgement that methods and classes are useful means of structuring 
in the case at hand. Seen from the perspective of an effectuating machine it 
may be preferable that a particular method is performed by another machine, 
which comes close to it being outtasked by that machine, thus leading to remote 
method invocation, or in terms of our topic: method effectuation as a service 
(MEaaS). 

Rather than viewing decisions as very particular actions taken by agents 
or by organizations, decision may be seen as a way to structure organizational 
behavior. For instance it may be "decided" (at the level of organizational design) 
that certain actions need to be preceded by decisions so that these actions can 
be understood as the effectuation of decision outcomes. That is useful only if 
a protocol for decision taking, as well as for the preparatory part of decision 
making is laid down as well. 

From this perspective it is plausible that if an organization U plans to make 
use of DTaaS it may need a preparatory phase for structuring its operations in 
such a way that DT takes a more prominent place to begin with. In particular 
DT may then take place as a thread amongst other threads in a multi-thread run 
by way of strategic interleaving by some managing body0 The transition to- 
wards DTaaS where some external agent s provides a similar thread as a service 
to U's management body may be understood as temporary thread migration. 

DT as provided by an internal service must be monitored internally from 
the perspective of DT demand management. Only if it is known what non- 
DT threads expect from a DT thread it can be agreed what to expect from an 
external provider of a DT thread. 

3.2 Decision-free operation 

The presence of a systematic DT process is likely to lead to burocratic overhead. 
Introduction of DTaaS seems to work in the opposite direction. Application of 
DTaaS is only possible if DT can be seen as a disposable feature. An organi- 
zations existence need not involve much decision taking. Here is a list of what 

In our understanding of the act of voting a vote may be cast by an agent without having any 
intentions in mind. 

12 Changing an organization into a mode of operation where decision taking is more promi- 
nent has virtues outside the context of DTaaS. Achieving such transformations may be valu- 
able if increased accountability and transparency are sought. Of course the converse holds 
as well: turning decisions into mere choices may be helpful if accountability, traceability, or 
transparency are to be diminished. 
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can be performed outside decision taking. 



1. Can an organization can do without DT altogether, and if so to what 
extent? Yes, and indeed many activities and actions while not counting 
as DT lead to results comparable to DT: 

• meeting, conferencing, brainstorming, 

• monitoring, logging, writing and distributing meeting minutes 

• data mining, desk research, interviews, opinion polling, 

• creation and mining of feelings and opinions, possible mediated by 
interaction promoting IT tools, 

• planning, 

• promising (for promises not qualifying as decision outcomes, see Sec- 
tion 12.31 below. 

• voting, social choice, 

• choice from different alternatives, followed by action, 

• choice from different alternatives followed by plan formation (though 
without taking action), 

• improvised action, 

• deliberate individual action, 

2. Is top management intrinsically connected with DT? No, management 
tasks may be confined to: 

• providing a sense of direction, including a mission 

• providing objectives and goals including a strategy, 

• providing a policy preferences and tactical options. 

Each of these aspects can be influenced by means of informal steps which 
fail to qualify as DT. 

3. Mission statements, strategic directions, and policy preferences can be 
set without making use of DT. Of these matters have been communicated 
effectively to the workforce of U each of its members is in a better position 
to act when actions involve making choices that may discard options, or 
to perform actions that will create new options for future activities of U. 

4 On services and service casting 

A service is defined as an identifiable and intangible activity that is the main 
object of a transaction in [3H] (see also ) . I will use a somewhat more detailed 
definition of a service, useful in particular to separate services from products, 
that was used in [30]. In [30] the distinction between products and services is 
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clarified by means of an extensive quote from [33]. In brief a service is sold 
by one party to another, but as opposed to product, it is intangible (as an 
entity), heterogeneous (as a concept), it is perishable (non-enduring), and it is 
necessarily consumed and produced concurrently. According to |30j . however, 
services may carry products along and products may carry services along, the 
difference being a matter of gradation rather than a very sharp one. One may 
perhaps simplify these requirements to the condition that a service is a process 
which can be provided against compensation by a third party. 

4.1 Casting activities and products as a service, a cata- 
logue of examples 

In [23] "music as a service (MaaS)" is explained to be the transfer of music in 
digital form, by way of streaming without transfcrral of ownership of the data. 
MaaS is seen as an instance of content as a service (CaaS). Now if one listens 
to ordinary live music the suggestion that ownership is transferred has never 
been present, and that suggests that live music has always been music as a 
service. However, in order to grasp the phrase "music as a service" on needs to 
understand that live music is not meant as it would be odd to look for a new 
name for such a classical phenomenon. For that reason the phrase MaaS lives 
in another world, most plausibly the digital world, where music as a a product 
is known, and music as a service may be a novel phenomenon. More can be 
said, however: the provider of live music cannot concurrently serve different 
customers with different tunes, whereas a digital service provider is supposed 
to be able to serve different clients at the same time in ways more flexible than 
mere broadcasting. This concurrency criterion on service provision is absent in 
the discussion of [3U] but it seems to be a helpful addition to understanding 
what is amenable to service provision and what is not. 

In [33] business dashboards as a service are discussed. As far as I can see the 
authors fail to explain the plausibility of service casting in this case. Instead 
they merely analyze the virtues of dashboards (implemented as an interactive 
tool for business data visualization) for management purposes as well as the 
need for further research about them. The phrase "dashboards as a service" 
suggests the presence of a third party collecting a client's business information 
and extracting from that a clever abstraction which is provided to the client in 
the form of a dashboard, which itself is an internet service. This is a plausible 
explanation of what "dashboards as a service" might amount to, irrespective of 
the extent to which that constitutes a realistic IT market opportunity at this 
moment in time. In the discussion of [30j from which we have already quoted 
criteria for the distinction between product and service, the presence of a third 
party arises from their condition that a service can be sold by one party to 
another. 

In [5B] the usage of "(security) policy as a service" is explained in the context 
of cloud security. This is a convincing example of service casting. A security 
policy is intangible and non-product like but its real time provision by a third 
party (and hosted in the cloud) may be understood as a novel feature. 
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In [35] one finds an elaborate description of (software) "composition as a ser- 
vice" (abbreviated as CaaS in [35] but here as SCaaS in order to avoid confusion 
with "content as a service" ) . SCaaS is presented a a phenomenon in the context 
of software as a service (SaaS). SCaaS differs from SC by its provision by a third 
party which justifies service casting in this case. Software composition satisfies 
all requirements in the entities traded as services as formulated in [30] . 

In |16j a description of cloud computing is given with a focus on "infrastruc- 
ture as a service" (IaaS). IaaS is considered the most generic service provided 
by a cloud in addition to PaaS (platform as a service, see also [57]) which is 
committed to some fixed systems software, and SaaS (software as a service) 
which in addition implies a commitment to an application area and a family of 
software products applicable to that area from which services may be composed 
automatically on demand. The phrase IaaS is difficult to grasp because infras- 
tructure primarily refers to a product rather than to a process. It seems to be 
more precise to speak of "infrastructure behavior as a service" (IBaaS) instead. 

In pQ flexibility as a service (FaaS) is proposed. Although flexibility is no 
more than an attribute of a service offering, this instance of service casting is 
based upon the fact that principles of service composition can be provided in 
such a way that flexibility results. Remarkably, "services as a service" (SVaaS) 
becomes meaningful if it implies a focus on service construction by means of 
systematic composition in real time at the provider side. As [T] points out, 
FaaS is an objective which can be obtained through what I just termed the 
SVaaS perspective. 

Software as service is currently the most well-known instance of service cast- 
ing, by which all other instances seem to have been inspiredlll I will now discuss 
this example of service casting in some detail. 

Finally an interesting case is "politics as a service (POLaaS)" POLaaS 
(often written PaaS, which unfortunately collides with "platform as a service") 
has a formidable presence on the internet. 

4.1.1 SaaS, SEaaS, SENaaS, STaaS, and SPaaS 

In spite of software constituting a product (tangible good) rather than a process 
(intangible good), SaaS (software as a service, see [ID]) is at present the most 
prominent instance of service casting. 

Because software is effectuated when used, "software effectuation as a ser- 
vice" (SEaaS) makes perfect sense, (with AHaaS for "application hosting as a 

13 If software is identified with "families of polyadic instruction sequences", an identification 
which I consider to be adequate, it becomes reasonable to understand software as a mathe- 
matical entity, which is intangible rather than tangible. Of course the physical representations 
of mathematical objects are tangible, but the mathematical objects themselves are not, or not 
necessarily. Thus I will identify computer software with "(conventional) physical representa- 
tions of families of polyadic instruction sequences" , thereby rendering software tangible. 

14 The late Dutch politician Pim Fortuyn made headlines in the Netherlands with his slogan 
"at your service" , which may be understood as his intention to provide POLaaS to the Dutch 
public. The extent to which POLaaS is a credible option that escapes from the problems 
of plain power oriented populism still puzzles Dutch political commentators ten years after 
Fortuyn's violent death in 2002. 
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service" as the more common name). SaaS goes beyond SEaaS however, as it 
also comprises the on demand and real time composition of services (as provided 
by software being effectuated) , and it may include the provision of software from 
a remote server. SEaaS and SENaaS are both included in SPaaS (software pro- 
cess as a service), which goes beyond SEaaS and SENaaS by taking all phases 
of the software life-cycle into account. SPaaS also comprises the service area 
STaaS (software testing as a service, also known as TaaS) and SDaaS (software 
development as as service). Another option is PRSaaS for providing software 
as a service. 

4.1.2 (Provision of software) as a service = 
provision of (software as a service)? 

The background of all service casting expressions XaaS might, if only as a 
thought experiment, be understood as follows: (i) XaaS is a service, (ii) every 
service H is identified with providing H, (which is abbreviated to PR H). Thus: 
XaaS = PR (XaaS), (hi) associativity of bracketing is used PR (XaaS) = (PR 
X)aaS. In the case of software: 

Software as a service = providing (software as a service) = (providing soft- 
ware) as a service. 

Identification of a service casting with its provision may be considered im- 
precise, and that leads to contemplating inverse-provision as a kind of inverse 
operator for service casting. If inverse-provision denotes the abstraction from 
the phenomenon of the provision of a service to the abstraction consisting of its 
underlying service then one obtains the equation: 

XaaS = inverse-provision ((provision of X) as a service). 

This explanation of service casting would have the effect that it renders every 
service casting plausible, which is itself an implausible state of affairs, which for 
that reason I will not take it seriously. 

4.2 Plausibility of service casting 

I will use concept as a category that includes, entity, service, process, prod- 
uct, and method. For each concept X, the service casting of X, [X]aaS can be 
contemplated. Service castings range from implausible to plausible. X satisfies 
the so-called service casting preconditions of Paragraph s. 31 below if and only if 
[X]aaS is a plausible service casting. 

The question arises which cases of service casting are plausible. That ques- 
tion is seemingly paradoxical in the following sense: if X is a service then XaaS 
makes little sense because [X]aaS suggests that X is seen from the service per- 
spective, instead of its "natural" perspective. 

4.2.1 Implausible cases of service casting 

If X is not nearly a service then it may defeat being viewed from a service per- 
spective. Here are some examples. None of the following service castings seems 
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to make sense: "jogging as a service" , "meaning as a service" , "gold ownership 
as a service" , "medication as a service" , "bicycles as a service" , "hardware as a 
service" , "sleeping as a service" , "breathing as a service" , "flying as a service" , 
"consciousness as a service", "being born as a service", "self-confidence as a 
service" , and "dining as a service" . 

4.2.2 Unclear cases of service casting 

There are unclear cases as well. At this moment I have no judgement available 
on the plausibility of the following potential service castings: "choice as a ser- 
vice" , "social choice as a service" , "owning as a service" , "spying as a service" , 
"swimming as a service" , "natural numbers as a service" , "walking as a service" , 
or "happiness as a service" 

4.2.3 Service casting obstacles 

Service casting obstacles are preconditions on a concept X that render XaaS 
implausible under all circumstances. Two such conditions can be identified at 
this stage: X is a service already (a violation of this condition will be labeled as 
weak implausibility of the service casting at hand), and non-disposablity, that 
is after outtasking or outsourcing X from U, an unacceptable loss of identity of 
U has occurred. 

4.3 Service casting preconditions 

The following conditions on X must be met for [X]aaS to be plausible P^l 

Ontological constraints. Preferably X satisfies the criteria listed in |30| for 
services. To meet those criteria X needs to be intangible, and non- 
enduring, and P's production and consumption must be necessarily con- 
current. Preferably X is a kind of activity rather than a kind of entity. If 
X is tangible the following clause applies. 

Service casting preconditions for product classes. If X is product-like (tan- 
gible) rather than service- like (and therefore intangible) and if [-]aaS is 
instantiated to XaaS, then the following conditions must be met: 

1. XaaS will provide processes P that usually represent the usage of X 
(or of instances of X)Fl and, 

15 In contrast "well-being as a service" (often referred to as wellness service) is plausible. 

16 Plausibility is a semantic notion purely related to the amenability of X for being offered 
as a service, or for suggesting a clear interpretation of [X]aaS which is to be distinguished 
from usefulness of [X]aaS, once it has been accepted as a plausible concept, for its consumer 
and producer. 

17 If XB represents the behavior of an X (or of an instance of X) then XaaS is understood 
as XBaaS by default. 
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2. if a process P representing the usage of X (or of an X) can be provided 
through the internet, services as meant by HaaS will be delivered as a 
webservice, and several customers may be provided the same service 
at the same time. 

3. if P is most likely is to be provided via the internet, and if normal 
effectuation of the process X does not involve human operation then 
HaaS will definitely not involve human operation^ 

Significant deviation from normal casting. The concept X is not normally seen 
as a service A violation of this precondition amounts to weak implausi- 
bility. Weak implausibility does not imply incoherence, it merely implies 
service casting is applied in an implausible case. From these considera- 
tions it follows that casting activity, or entity, X as a service requires that 
the audience for the phrase "X as a service (abbreviated XaaS)" accepts 
the following implicit ambiguity: 

• X must not a service by default. But the difference between the 
default role of X and its role after being cast as a service should not 
be too large either. If it is too large one arrives at implausible service 
castings, some of which have just been listed. 

• The more distant XaaS is from the normal role of X the more suc- 
cessful the notion XaaS may become. Probably SaaS has acquired 
significant popularity just because software is commonly understood 
as a product. 

self X is the normal (default) case. If X is normally a service it can be placed 
in the context self[-] thus obtaining "self[X]"o If it is explicitly meant 
that X is understood in its default meaning that can be expressed with 
"X as usual" 

Demand management phase is an option. As a preparation for a XaaS phase 
for its prospective consumer U it may need to structure its own processes 
in such a way that X is performed as self[X] by U, though in a separate unit 
which is monitored and managed with principles of demand management. 

Disposability. It must be the case that stripping X from a unit need not 
necessarily imply a loss of its identity. 

Concurrency potential. Implicit in a offering a service X to U is that a can, at 
least in principle, offer the service X concurrently to a plurality of clients. 

18 In the case of SaaS (software as a service) this constraint explains why SaaS will not extend 
to "software engineering as a service" (SENaaS), a "product" involving human engineers that 
has been delivered by the software industry for many years. 

19 I propose to call "online banking as a service" weakly implausible because online banking 
is normally considered a service. 

20 For instance self hairdressing. 

21 For instance: "self hairdressing" is probably cheaper than "hairdressing as usual", thus 
avoiding "hairdressing as a service" which is weakly implausible. 



16 



This form of concurrency can be described by strategic interleaving for 
multi-threading as outlined in [12]. That concurrent offering of X is an 
option is a property of X and it can be understood as a service casting 
precondition. 

Potential for co-creation of the service by provider and consumer. It is some- 
times proposed as a key aspect of services that these are co-created by 
producer and consumer. 

5 DTaaS 

After considerable preparations a "formal" (in the sense of "official" ) introduc- 
tion of DTaaS is now enabled. The introduction splits in four parts: (i) creating 
DTaaS as a (meaningful) concept, (ii) a survey of DT specific aspects of DTaaS 
instances, (iii) a survey of potential advantages of DTaaS for its consumer and 
provider, and (iv) a survey of risks and potential disadvantages for RTaaS. 

5.1 DTaaS: a definition 

As a concept, DTaaS is the result of service casting applied to the concept DT. 
For this result to be well-defined compliance with the various service casting 
preconditions needs to be checked. This matter will be addressed in Paragraph 
I5TH below. 

Each instance of DTaaS involves a unit and an agent. DTaaS refers to a 
particular kind of sourcement: DTaaS occurs if an agent a provides DT as a 
service to a unit U. In the case that a provides DTaaS to U, the decisions taken 
by a are taken on behalf of U and have the same status as decisions taken by 
C/'s management. 

Much can be said about instances of DTaaS which is specific for DT as a 
concept. For instance that this sourcement is likely to have arisen by outtasking 
a part of f/'s DT to a, where outtasking refers to a temporary transfer of an 
activity (task) to another unit (the unit containing a) without a corresponding 
transfer of sources. In Paragraph s. 21 a range of further observations concerning 
instances of service casting DT, which are specific to DT rather than to service 
casting in general, is made. 

5.1.1 DT meets service casting preconditions 

DT is intangible, and it is not normally cast as a service. Further self DT is 
the default situation and demand management for DT is an option, though in 
order to understand that option one probably needs an awareness of the notion 
of DTaaS already. DT is disposable in some cases and a DTaaS provider may 
concurrently provide DT services for different clients. By developing adequate 
DT protocols, a DP task which may be shared with the client, co-creation of 
DT services between provider and consumer may be achieved. 
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5.1.2 DTaaS avoids service casting obstacles 

DT is not usually considered a service, and outtasking DT need not degrade a 
unit's identity. In 13.21 a listing has been made of the activities that differ from 
DT and that will remain after outtasking DT. 

5.2 DTaaS: DT specific aspects 

The purpose of this section is to specify the result of service casting of DT, and 
more specifically of DT/ (leading to DT/aaS) for some decision interface /, in 
greater detail than merely stating that it results from service casting. 

5.2.1 Which decisions can be delegated? 

Which decisions can be delegated to a service provider? Because it is hardly 
conceivable to hand over "all DT" to an external agent, there is no way around 
some form of modularization. To that end one may take advantage of the 
concept of a decision interface (DI), which collects a coherent family of issues or 
topics about which decisions may be taken. Elements of a decision interface are 
sometimes called decision rights, but that is asymmetric as these elements may 
equally well be understood as decision obligations (or more neutral, decision 
tasks, decision options, or decision patterns). The notion of a decision interface 
is symmetric. It is understood that an agent having regular DT as its task 
may collect all of its potential decisions in an overall DI which is modularized 
(decomposed) as a combination of disjoint sub DI's. 

Given a decision interface /, DT/ represents DT concerning decisions in /, 
DM/ stands for DM concerning decisions in / and DP/ concerns DP limited to 
decisions in /. We have the following /-specialized equation "DM/ = DP/ + 
DT/." 

In [3] it has been argued that DT requires that the the DT agent operates 
in a clearly determined role. Thus some role must be provided, at the least this 
role is the following "external DT agent on behalf of U" , or "external DTaaS 
provider for U" , or simply "external decision taker for U" . The role name is 
likely to be linked to the decision interface for which the role has been sought. 

It is an existing practice that external DTaaS is sought for brief episodes 
and dedicated to a single issue or to a very confined range of issues, the role of 
an external DTaaS provider has more intrinsic names, for instance a jury, if a 
prize is to be awarded on behalf of U, 

Further examples of role names for thematic episode driven instances of 
DTaaS (abbreviated as EdDTaaS) with limited scope: (i) a mediator if media- 
tion is sought for a conflict between subunits within U (and DTaaS is applied 
because mu may not be considered sufficiently impartial, or may not have the 
required authority or trust base within U, (ii) a court if U has sought the in- 
tervention of a legal process, (iii) some specialized authority (e.g. the EFSA, 
European Food Safety Authority) which is asked to intervene, (iv) an active pri- 
vate banker who may trade on behalf of its clients, (v) a mountaineering guide 
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is in charge of a well understood part of his/her client's DT during a trip, (vi) 
an auctioneer decides about transactions between parties who have each agreed 
to stay within the protocol prescribed by the auctioneer. 

5.2.2 What sourcing options exist for DT? 

Having stated that an instance of DTaaS is a sourcement of a particular kind, 
it is useful to consider in some detail which sourcements may allow an external 
agent a to perform DT (or DT/) on behalf of the management mu of some unit 
U? Here are some observations concerning that matter. 

• Unit management may be self-sourcing for DT, that is mjj performs DT 
(in other words it applies self DT). This is most common and I will assume 
that it is the case by default. 

• DT may have been delegated by mjj to one or more subunits at a lower 
level in U's management hierarchy. In this case U is self-sourcing for DT 
but mu is not. 

• U may well distinguish between governance (gu) and management (mu), 
in which case it is the role of gu to delegate DT to management functions 
within U. 

• if gu temporarily delegates DP to an interim manager imu instead of 
to my, U is still self-sourcing for DT because imu operates under the 
responsibility of gu- 

• U may be temporarily non self-sourcing for DT. That means that DT has 
been temporarily delegated (outtasked) by gu to an agent a operating 
outside U. In this case a acts as a service provider for mu- The authority 
and steady support of gu is required to assure that a is in a decision taking 
role rather than merely in a consulting role where it may at best suggest 
potential decision outcomes to mu- 

As long as gu keeps the outtasking relationship between U and a in place 
m;/ accepts the decision outcomes of a decisions as if these were decision 
outcomes brought about by its own decision taking. It is essential to 
specify in advance which types of decisions constitute part of the DTaaS 
agreement, because mu cannot undo a's decisions any easier than its own 
decisions. 

5.2.3 Which sourcement transformations exist for DT? 

In [11] the notion of a sourcement transformation has been examined in detail, 
with a particular focus on the following transformations: outsourcing, insourc- 
ing, backsourcing, and follow-up outsourcing. Without further analysis I will 
postulate that corresponding transformations can be found if only tasks but no 
sources are being transferred: outtasking, intasking, backtasking and follow-up 
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outtasking. For the case of DTaaS the outtasking transformation is of particular 
importance. 

• DT cannot be outsourced. This is so because outsourcing of DT (from 
a state where it is performed by my) involves moving mjj (or a part of 
it) outside of U, which cannot be done unless the characteristic feature 
of its being the management of U is lost. An artificial option which I 
will discard as being unconvincing is to give members of mjj part-time 
positions in an insourcing unit U' outside U. 

Another artificial opting that is mentioned only is that given the decision 
interface I, the body mu is decomposed as mjj = mf} 1 Um^'' into disjoint 
groups m'fj 1 (involved in decision taking about decision patterns in 7) and 
rri^f' 1 (not involved in decision taking concerning decision patterns in J), 
and to assume that rn^f' 1 is outsourced by U to a. This option is artificial 
because it casts doubts on the status of mjj as a managing body in the 
original situation. 

• outtasking of DT is possible, a consequence that being that the tasks of 
mjj are temporarily reduced. 

• Task extcrnalization is not an option for DT. Indeed it is against the 
required autonomy of U as being an independent unit if DT is transferred 
to an external agent on an indefinite basis. Thus the feature of outtasking 
that it comprises a temporary transfer of tasks is essential in the case of 
transferral of DT. 

• If DT has been outtasked to agent a, that agent is called an external 
decision taker on behalf of U. 

• Because DT cannot be outsourced and DT is a part of DM, only partial 
outsourcing of DM is possible. In particular only partial or full outsourcing 
of PM is possible. 

• Typically DP or parts of it can be outtasked to a so-called consultant. 

• By definition DT cannot be outtasked to a consultant (in its role as a 
consultant). 

5.3 Possible reasons for using DTaaS 

DTaaS is a (potentially) meaningful concept in the sense that it may open a 
novel perspective on organizational architecture. DTaaS seems to be uncommon 
except in cases where quite dedicated DT processes are outtasked and often in 
a case by case fashion only. 

DTaaS will be initiated by the outtasking unit U, or rather by its governing 
body (subunit) gu which will make use of the DT services of agent a which may 
be a part of unit U' instead of having that part of DT self-sourced for U by mp. 
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For doing that gu needs plausible reasons. These reasons will differ from case 
to case but some general remarks concerning these reasons can be collected: 

• DT provider a may be less vulnerable to the effects of stress created by 
an involvement in DT concerning U than mjj. Even a's authority or trust 
base may exceed that of mu- 

• DT provider a's awareness of the consequences of possible decisions to 
parties outside U may significantly exceed that of U. 

• DT provider a may include highly skilled DT specialists who are especially 
competent in: (i) timing of DT, (ii) prediction of the effects of implement- 
ing potential decision outcomes, either tactically or strategically, or both, 
(iii) managing the core of DP preceding DT, (iv) evaluating the quality 
of preparatory DP activities may exceed that of mu, (v) drafting decision 
outcomes, (vi) communicating decision outcomes. 

• DT provider a may be able to apply process models to DT which it has 
used elsewhere and by doing so perform at a higher level of competence 
compared to the competence level provided by the DT function within 
U. For instance a may be well placed to deal with (that is to guarantee) 
abstraction (preventing information from leaking to third parties) and 
encapsulation (preventing external interference) for the decision processF^I 

• Every decision may be understood as the effectuation of a decision taking 
thread, itself the result of putting into effect an underlying instruction 
sequence (e.g. see [2]). Effectuating such instruction sequence^] may be 
a particular competence of a. 

• As argued in [6] DT may involve multi-threading (see |12| ) in the case 
of DT for U. As a may be providing DTaaS services for several different 
clients simultaneously a may be dealing with hierarchical multi-threading 
(see [IS])- More efficient methods for strategic interleaving of hierarchical 
decision threads may be available to a than to mjj. 

• By outtasking DT mjj arrives at a situation where it can concentrate on 
putting decision outcomes into effect. In that case mjj may operate in 
an almost decision free fashion. Once decision outcome effectuation has 
become standard practice my may terminate outtasking DT or part of it. 

• For U it may be helpful to forget about short term tactical DT in order 
to fully concentrate on long term strategic matters. The opposite may 
hold as well: mu makes use of DTaaS provided by a hoping that a is 
able to deal with long term and strategic matters while mu is capable of 
operating with full concentration on tactical and sort term issues of vital 
importance to it's existence. 

22 Abstraction and encapsulation are notions from process theory ([4]) which find an appli- 
cation in many decision making process. 

23 In particular these instruction sequences may involve conditions written in the notation 
of short-circuit logic, which is semantically analyzed by proposition algebra (see |15|). 
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• DTaaS can be used to reduce the burocracy in the outtasking organization. 
Burocratic simplification can conceivably be achieved by training staff to 
perform a significant amount of action without the need for DT processes, 
thus reducing the volume of DT and outtasking a part of the remaining 
DT may further reduce the dependency on DT. Once DT is out of the 
way business process optimization and automaton can both be used to 
streamline an organization's workflow. 

• DT provider a shares the responsibility of its decisions, and concerning 
the consequences with the unit U to which the service is provided. The 
legitimacy of a having these responsibilities has several sides, but a suf- 
ficient criterion is that gu which is in charge of ultimate responsibilities 
for U can argue convincingly that it is in £/'s best interest to outtask DT 
to a. In particular if an emergency of a particular kind has to be dealt 
with, a's competences to deal with the variety of issues connected with 
that particular kind of emergency may be valued of higher importance 
than conformity of a's own intentions with achieving some or all of ZJ's 
strategic objectives. 

5.4 DTaaS risk analysis 

There is a plethora of potential risks that DTaaS carries with it for its consumer. 
I will mention only a few aspects of the risk analysis. 

• There may be a risk of vendor lock in when U makes use of DTaaS provided 
by a If DP is outsourced to a there is a risk that U may not be able to 
realize backsourcing of its DM activities, thus becoming dependent of a. 
This is a reason for not outsourcing DP to the same service provider as the 
one to which DT is being outasked. It even suggests that outsourcing DP 
brings with it a higher risk of vendor lock in than outtasking DT may do. 
If only DT has been outtasked to a, U must make sure, and communicate 
that backtasking DT from a is an option at regular instances of time. 

• Like in the case of an external consultant C/'s appreciation of a's services 
may degrade. In that case a's staff may withdraw from its involvement 
in a DTaaS sourcement if its authority has become problematic and its 
activity is less effective. 

• Is DTaaS a common practice or is it a mere thought experiment? DTaaS 
for short episodes or limited to relatively confined decision classes is com- 
mon practice, but DTaaS for the full width of mjj decision rights seems 
to be unusual. That creates the risk that an occurrence of DTaaS is taken 
to be a sign that mu fails to live up to its expectations. In fact mjj seems 
to carry an obligation to take the majority of its own decisions itself. 
DTaaS is about the thought experiment that this obligation is replaced 
by a less restrictive policy towards the range of task descriptions suitable 
for a management agent or team mu- 
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• Assuming that a provides DTaaS to different units a conflict of interest 
arises if at the same time a needs to strive for opposite objectives Be- 
cause a is taking decisions it does so with the awareness of expected con- 
sequences (of effectuation of decision outcomes) and with the (delegated) 
intention to effect these consequences. That intentions can be delegated 
at all is open for discussion, and I will assume that when acting as a DT 
provider for U, a may pretend intentions (on behalf of a) that are not 
quite its own, provided that these intentions comply with a's best and 
own intention to maintain a bundle of pretended intentions on behalf of 
U that best serves U's interests, and to do so in a consistent fashion. 

6 Concluding remarks 

This paper contains a theory of DTaaS and following [TO! it is fitting to ask 
about the intended audience of that theory and to ask what members of that 
intended audience might get out of it. In the terminology of [TU] the latter 
question is phrased as to what ability or which conjectural ability is supposed 
to result from an acquaintance with this theory. These conjectural abilities 
are twofold: the ability to acquire a DT task and to start acting as a DTaaS 
provider (intasking DT, the transition complementary to outtasking DT), and 
the ability to outtask part of one's DT activities in order to concentrate on 
other activities which are considered to be of higher importance in some stage. 
Returning to the matter what constitutes an intended audience for this paper: 
those potential readers who take an interest in decision taking and have accepted 
the preparatory analysis made in [BJ. 

An analysis of service casting has been provided as well as a demarcation 
of decision taking separating it from choice, individual voting, social choice, 
and obligation creating promise issuing. Using these ingredients the conceptual 
coherence (consistency) of DTaaS has been established and potential advantages 
of its use have been indicated. 

Further work can be descriptive, aiming at finding instances of DTaaS in ex- 
istence and investigating how that came about and what advantages are actually 
obtained. Another and perhaps more attractive path is to investigate existing 
organizations or projects and to find suggestions for first making DTaaF more 
visible in the organization (or project) and subsequently outtasking a part of 
DT so that DTaaS is made use of. 

As an application of this work DTaaS can be introduced in pilot organiza- 
tions or projects in order to find out which of the mentioned potential advantages 
can be achieved in practice, and if so under what circumstances. 

24 Less apparent than an outright conflict of interest is so-called feature interaction (see 
1251 ). If a is involved in providing DT services for different units it needs to analyze feature 
interaction between its respective decision interfaces. A conflict of intentions is an obvious 
instance of feature interaction, but more subtle interactions will need attention as well. 
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